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(54) TiUe: METHOD FOR INITIATING WORKFLOWS IN AN AUTOMATED ORGANIZATION MANAGEMENT SYSTEM 



(57) Abstract 

A computer program (38) for organization manage- 
ment can interact with a database (36) containing organ- 
ization information, and includes a pcrsonel administra- 
tion module (41), a personnel development module (46), 
and a workflow engine (43). The personnel administration 
module can interact with the workflow engine to initiate 
a workflow to obtain approvals for a proposed change in 
the database, A supplemental program (51) is provided 
to permit the personnel development module to cause the 
workflow engine to initiate a workflow in association with 
a proposed change, and can interact with a scenario table 
and a scenario attributes table. The scenario table identi- 
fies different types of proposed changes, and identifies the 
particular workflow process to initiate for each such type. 
The scenario attributes table identifies one or more pro- 
posed changes which fall within each type, and indicates 
whether it is necessary to initiate a workflow for each such 
change. 
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METHOD FOR INITIATING WORKFLOWS IN AN 
AUTCHATED ORGANIZATION MANAGEMENT SYSTEM 

5;TATRMF!WT RECARnTWr, rOPYRTCTT RIGHTS 

A portion of this patent disclosure involves material 
which is subject to copyright protection. The copyright 
owner has no objection to the facsimile reproduction by 
5 anyone of the patent dociment or the patent disclosure/ as 
it appears in the Patent and Trademark Office patent file 
or records / but otherwise reserves all copyright rights 
whatsoever. 

10 TECHNTCAI. FTPT.D OF THE TWVEWTTQN 

This invention relates in general to automated 
techniques for organization management and, more 
particularly, to the capability for initiating a workflow 
within an automated organizational management system in 
IS order to obtain approvals for a proposed change* 

BACKGRQUCT OF THE INVENTTQN 

As computers have become progressively more common in 
the workplace, the tasks associated with organizational 

20 management have become progressively more automated. One 
known computer program for organizational management is 
available under the tradename SAP (Systems, Applications 
and Products in Data Processing) , which is commercially 
available from SAP AG in Germany. The SAP program is 

25 designed to provide support, for all aspects of what an 
organization may wish to do. 
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One aspect of the capabilities of the SAP software 
relates to support for human resources. In this regard, 
the SAP software has a personnel administration module, 
which handles matters specific to a particular" employee, 
5 such as the en^jloyee's pay rate, in^slementation of a raise, 
implementation of a bonus, vacation time, sick time, and so 
forth. The SAP software also has a personnel development 
module, which handles matters such as an inventory of 
employee skills, an inventory of employee training and 

10 education, work force planning functions, and 
organizational management issues such as maintenance of the 
organizational hierarchy. Maintenance of the 

organizational hierarchy may include matters such as a 
permanent internal transfer of an engployee, a temporary 

15 internal assignment or transfer of an employee, a change in 
the job code for a position, or filling a position from a 
source external to the organization. The SAP software also 
includes a workflow engine, which is capable of 
automatically obtaining the necessary approvals for a 

20 proposed change. 

While the existing SAP program has been generally 
adequate for its intended purposes, it has not been 
satisfactory in all respects. For example, the personnel 
administration module is capable of interacting with the 

25 workflow engine in order to initiate or trigger a workflow. 
However, the personnel development module does not have the 
capability to interact with the workflow engine or trigger 
a workflow. 

As one specific example, in the case of a permanent 
30 transfer of an employee from one position to another within 
the organization, the necessary approvals must all be 
obtained in advance in a manner external to the SAP 
program, for example by circulating a memo or other paper 
document. Then, after the necessary approvals have all 
35 been manually obtained, the proposed change can be manually 
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implemented through the personnel development module, by 
one or more selected employees who have the authority to 
implement changes. However, in view of the progressive 
trend toward distributed processing, where the majority of 
5 employees have a computer, and where computers in 
geographically remote portions of an organization ar'e 
typically linked, it is desirable for the approval process 
to be automated. A further consideration is that, even in 
the personnel administration module, each proposed change 
10 must be submitted immediately for is^lementation, which is 
not always desirable or convenient. 

StJMMftRY QF THE TNYKfTnON 

From the foregoing, it may be appreciated that a need 

15 has arisen for a method for effecting automated 
organizational management, which includes the capability 
for workflow, which preferably includes the capability to 
save proposed changes without submitting them immediately 
for implementation, and which preferably includes the 

20 capability to simultaneously implement several proposed 
changes that were previously saved. According to the 
present invention, a method is provided to address this 
need, and involves: maintaining a database of information; 
accepting from a user through a user input apparatus a 

25 proposed change to the database and a specified status 
therefor; saving a proposed change when the specified 
status therefor is a first status, without initiating 
implementation thereof; and processing a proposed change by 
initiating implementation thereof when the specified status 

30 therefor is a second status different from the first 
status, the processing step including the step of 
initiating a workflow where the proposed change having the 
second status requires a workflow. 
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nf^TPf nr.qrRIPTTnW nr the DRAWTMnc; 

A better understanding of the present invention will 
be realized from the detailed description which follows/ 
taken in conjunction with the accon^janying drawings, in 
5 which: 

FIGURE 1 is a block diagram of a system which 
facilitates automated organizational management and which 
embodies the present invention; 

FIGURE 2 is a flowchart depicting the operation of a 
10 software routine which is part of the system of FIGURE 1; 

FIGURE 3 is a diagrammatic view of a screen which can 
be displayed for a user by the routine of FIGURE 2; 

FIGURE 4 is a diagrammatic view of another screen 
which can be displayed for a user by the routine of 
15 FIGURE 2; 

FIGURE 5 is a flowchart depicting the operr :ion of 
further software routine which is part of the ystem of 
FIGURE 1; 

FIGtTRE 6 is a diagrammatic view of a screen which can 
20 be displayed for a user by the routine of FIGURE 5; 

FIGURE 7 is a diagrammatic view of another screen 
which can be displayed for a user by the routine of FIGURE 
5; and 

FIGURE 8 is a flowchart depicting the operation of a 
25 further software routine which is part of the system of 
FIGURE 1. 

DETATLPn nr<;rRTPTIQN QF TWE TNVENTTQN 

FIGURE 1 is a diagrammatic view of a system 10 which 
30 embodies the present invention. The system 10 includes a 
computer 12 which functions as a server, and which is 
coupled by a network 14 to a plurality of client systems, 
three of which are shown at 17-19. The network 14 may be 
a local area network (LAN), a wide area network (WAN), a 
35 telephone line connection, some other type of network, or 
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a combination of these different types of communication 
iinJcs. The client systems 17-19 in the disclosed 
embodiment are each a workstation or personal computer of 
a Itnown type. The client systems may, for example, be on 
5 the desks of various employees of an organization, and the 
employees may be located in geographically remote 
locations. 

The server 12 includes a processor 26 of a known type, 
which executes a suitable known operating system 28. 

10 Various software application programs can be executed by 
the processor 26 in conjunction with the execution of the 
operating system 28, including input/output routines 31 
which facilitate communication between the server 12 and 
the network 14. The server 12 has a database 36 of 

15 information, which is stored in a not-illustrated memory or 
hard disk. In the disclosed embodiment, the database 36 
contains information for an organization such as a 
corporation, including human resource information such as 
the names of employees, employee pay rates, employee bonus 

20 information, employee vacation information, employee 
skills, eziployee training, employee education, employee job 
codes, and a chain of command from each en^loyee up through 
the management of the organization. In the case of a 
manager, all of the persons and/or other elements that are 

25 managed by a given manager constitute a "domain" of the 
manager. A manager cannot be a part of his own domain, A 
given manager can manage more than one domain, 

A further application program, executed by the 
processor 26 in conjunction with the operating system 28, 

30 is an organizational management program 38, which is 
intended to provide support for virtually all aspects of 
what an organization may want to do. In the disclosed 
embodiment, the program 38 is a software package which is 
commercially available from SAP AG of Germany under the 

35 tradename SAP (Systems, ^plications and Products in Data 
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Processing) • The SAP software 38 includes a number of 
different modules, which provide various types of 
functionality, including human resources functionality. 
The preferred embodiment of the present invention is 
5 disclosed in the specific context of an improvement to the 
human resources functionality of the SAP program 38, and 
therefore only a subset of the modules of the SAP software 
are illustrated and discussed here. 

More specifically, the SAP software includes a 

10 personnel administration module 41, a worJcflow module or 
workflow engine 43, and a personnel development module 46, 
as well as other modules which are not illustrated. The 
personnel administration module 41 is used to handle 
matters which are specific to a given employee, such as the 

15 employee's pay rate, raises, bonus pay, vacation time, sick 
time, and so forth. The personnel development module 46 is 
used to handle huinan resources matters at the 
organizational level, including an employee skills 
inventory, an employee training inventory, an employee 

20 education inventory, work force planning capability, and 
maintenance of the organizational hierarchy. Four 
functions of specific interest which are handled by the 
personnel development module 46 include an employee 
transfer, an employee work assignment, a job code change, 

25 and a source external situation. 

An employee transfer or assignment is a permanent 
transfer of an employee from one position to another 
position within the organization. The terms administrative 
assignment and employee transfer, as used herein, mean the 

30 same thing. A temporary duty assignment is a temporary 
transfer of an employee from one position to another 
position within the organization. The terms ten^orary duty 
(TDY) assignment and ten^orary transfer, as used herein, 
mean the same thing. A job code change is a change in the 

35 job code for a particular position, where it is to be 
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understood that the system recognizes a distinction between 
a position and the person who is currently filling that 
position. A source external situation occurs in 
circumstances where a position is to be filled by a person 
5 or employee from outside the organization, or in other 
words a "source external"- The personnel administration 
module 41 and the personnel development module 46 are each 
capable of interacting with the database 36, in order to 
read information from or write information to the database 
10 36. 

A workflow is an automated technique for obtaining the 
approval of two or more persons for some type of change to 
the information in the database 36, For example, if an 
employee is to be given a raise, it may require only the 

15 approval of the employee's manager. If the manager is 
implementing the change, then it is not necessary to obtain 
the approval of another person, and the change can be 
immediately implemented. On the other hand, if the raise 
needs to be approved by two managers in the enqployee's 

20 chain of command, then the workflow engine 43 will initiate 
a workflow in order to automatically obtain the approval of 
both managers. Then, after approvals have been obtained 
from both managers, the workflow engine will initiate 
implementation of the change. 

25 For example, the workflow engine 43 may route an 

electronic communication to the electronic mailbox of one 
manager. After that manager accesses the electronic 
communication and enters the necessary electronic approval, 
the workflow engine 43 will forward the electronic 

30 communication to the electronic mailbox of the second 
manager. After the second manager has accessed the 
electronic communication and entered the necessary 
electronic approval, the workflow engine 43 will 
automatically initiate an update to the database 36 in 

35 order to implement the approved raise. A technique for 
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handling the routing of workflows is disclosed in copending 
U.S. Serial No. 09/921,130 filed August 29, 1997, the 
disclosure of which is hereby incorporated herein by 
reference. 

5 In the SAP software 38, the personnel administration 

module 41 is capable of directly interacting with the 
workflow engine 43. Consequently, as to matters which are 
handled using the personnel administration module 41, and 
which require multiple approvals, the personnel 

10 administration module 41 can automatically trigger a 
workflow operation by the workflow engine 43. Initiation 
of a workflow operation is sometimes referred to as 
"publishing an event". 

In contrast, the SAP personnel development module 46 

15 does not inherently have the capability to interact 
directly with the workflow engine 43, and in particular 
does not have the capability to publish an event to the 
workflow engine 43 in order to trigger a workflow. 
Therefore, in accord with the present invention, a 

20 plurality of supplemental routines 51 are provided, along 
with a table structure 53 which includes two tables. These 
two tables are a scenario table and a scenario attributes 
table, which are respectively shown below in TABLE 1 and 
TABLE 2, and which are both described in more detail later. 

25 The supplemental routines 51 are executed by the 

processor 26 in conjunction with execution of the operating 
system 28. The supplemental routines 51 interface with the 
personnel development module 46 and also the workflow 
engine 43, so that on behalf of the module 46 the 

30 supplemental routines 51 can publish an event to the 
workflow engine 43 in order to initiate a workflow, thereby 
giving workflow capability to the personnel development 
module 46. The supplemental routines 51 can also read data 
from and write data to the database 36. 
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FIGURE 2 is a flowchart which shows in more detail 
certain aspects of the operation of the personnel 
development module 46 and the supplemental routines 51. At 
block 71, the personnel development module 46 displays on 
5 the display of one of the client systems 17-19 a further 
attribute change screen, which is a standard SAP screen, 
and which is not illustrated. The system then waits for a 
user to make a selection from several available options. 
At block 72, the user's selection is evaluated. In 

10 particular, if the user identifies a position by clicking 
on it and then clicks a CHAKGE FURTHER ATTRIBUTES button, 
which is not illustrated, control will proceed to block 73, 
which is the start of one of the supplemental routines 51. 
Alternatively, if the user makes any other selection, 

15 control will proceed at 74 to some other routine within the 
personnel development module 46, which is not necessary to 
an understanding of the present invention and is therefore 
not described in detail. 

At block 73, the supplemental routines 51 display a 

20 position attributes screen, which depicts current active 
attributes. FIGURE 3 is a diagrammatic view of this 
position attributes screen, which is a new screen that 
replaces one of the preexisting screens inherent in the 
personnel development module 46, At block 73, the 

25 supplemental routines 51 wait for the user to make a 
selection within the position attributes screen of FIGURE 
3. The user selection is evaluated at block 76. 

In particular, if the user clicks an ALL STATUS 
button 78, then control will proceed to block 81, which 

30 will be discussed later. On the other hand, if the user 
makes any selection other than the button 78, control will 
proceed at 82 to some other routine, which is not relevant 
to the present invention and therefore not depicted and 
described in detail. In block 81, the position 

35 attributes screen of FIGURE 3 is replaced with an expanded 



wo 00/19345 



PCT/US99/22005 



version thereof, which is shown in FIGURE 4 and which shows 
all attributes for the particular position in question. 
The screen has several CREATE PLANNED buttons 83-91/ which 
each correspond to a respective attribute. Also in block 
5 81, a determination is made of whether a workflow is 
already in progress for any of these attributes. For each" 
attribute which is found to have a workflow already in 
progress, a corresponding one of the CREATE PLANNED buttons 
83-91 is changed to a DISPLAY SUBMITTED button, and the 

10 rest of the line to the left of that button is grayed. 
This indicates to the user that each grayed attribute 
cannot ciirrently be selected for a change. Then, still in 
block 81, the system waits for user input. 

At block 96, the system checJcs to see whether the user 

15 has clicked one of the CREATE PLANNED buttons 83-91. If 
not, then control proceeds at 97 to some other routine, 
which is not relevant to the present invention and is 
therefore not described in detail here. For purposes of 
obtaining an understanding of the present invention, it is 

20 sufficient to describe what happens in response to 
selection of one of the CREATE PLANNED buttons 83-91. The 
CREATE PLANNED button 91 for a job code change has been 
arbitrarily selected for a detailed explanation below. 
However, it will be recognized that a generally similar 

25 technique is used to handle each of the other eight CREATE 
PLANNED buttons 83-90 in FIGURE 4. 

More specifically, at block 101 in FIGURE 2, the 
system checks to see which of the CREATE PLANNED buttons 
83-91 has been clicked. Assuming for the sake of example 

30 that it is one of these buttons other than button 91, 
control proceeds at 102 to some other routine. 
Alternatively, however, if it is determined at block 101 
that the user specifically selected the button 91, then 
control proceeds to block 103, where the system waits for 

35 the user to enter a new job code in blank 106 of FIGURE 4, 
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an effective date for the job code change at 107 in FIGURE 
4, and a reason for the job code change at 108 in FIGURE 4. 

Then, at block 111, the system checks to see if the 
blanks 106-108 have all been completed. If not, then 
5 control proceeds to block 112, where the system displays an 
appropriate error message, and then returns to block 173. 
Alternatively, if it is found at block 111 that blanks 106- 
108 have all been completed, then control proceeds to block 
113, where the system checks to see if more than one person 

10 is scheduled to hold this position over time. For example, 
the system may find that the person currently holding the 
position is due to be transferred out of the position at 
the end of the current year, and that a new person is 
scheduled to be transferred into the position at that time. 

IS If the system determines that more than one person is 
already scheduled to hold the position over time, then a 
change in the job code would create a problem and is 
rejected. More specifically, control proceeds to block 
112, where an appropriate error message is displayed, and 

20 then control returns to block 73. 

On the other hand, if only one person is presently 
scheduled to hold the position over time, then control 
proceeds from block 113 to block 114, where the system 
checks to see if the particular person identified in block 

25 113 is currently holding the F>osition. If not, for example 
if the person is not scheduled to assume the position until 
a future date, then the job code change is rejected, and 
control proceeds to block 112, where an appropriate error 
message is displayed. From block 112, control returns to 

30 block 73. Alternatively, however, if it is determined at 
block 114 that the only person scheduled to hold the 
position is currently holding the position, then control 
proceeds to block 116. 

At block 116, the system determines the title of the 

35 job which is associated with the new job code entered in 
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blank 106, and displays this title to the right of blank 
106. Then, the system waits for the user to take 
appropriate action, as evaluated at block 117. In this 
regard, the user has three options. The first option is to 
5 cancel the proposed job code change, and selection of this 
option causes control to proceed from block 117 back to 
block 71. A second option is to save the proposed job code 
change without initiating an attempt to inclement it. If 
the user selects this option, control proceeds from block 
10 117 to 118, where the system saves the proposed change with 
an indication that it has "planned" status, which means 
that the proposed change is being saved without any current 
attempt to implement it. From block 118, control returns 
to block 71. 

15 The third option available to the user at block 117 is 

to submit the proposed change for isqplementation. This 
option causes control to proceed from block 117 to block 
119, where the proposed change is saved with an indication 
that it has "planned" status. In addition, a mode 

20 indicator is set to "SA", which is an indication that the 
proposed change is being submitted for implementation by 
the screen of FIGURE 4. Control is then transferred at 120 
to a SUBMIT routine, which handles implementation of the 
proposed change, and which is discussed in more detail 

25 later* 

FIGURE 5 is a further flowchart which shows in more 
detail certain additional aspects of the operation of the 
personnel development module 46 and the supplemental 
routines 51 of FIGURE 1. In block 131, which represents a 

30 portion of the personnel development module 46, the system 
displays a staff assignment change screen, which is a not- 
illustrated screen standard to SAP and inherent in the 
personnel development module 38. The system then waits for 
the user to make a selection. Then, at block 132, the 

35 system evaluates the selection made by the user. 
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If the user taJces an action other than clicking a 
STAFF ASSIGNMENT button, control proceeds at 133 to some 
other routine, which is a standard part of the personnel 
development module 46, which is not relevant to the present 
S invention, and which is therefore not described in detail.^ 
On the other hand, if it is determined at block 132 that 
the user has clicked the STAFF ASSIGNMENT button, then 
control proceeds to block 136, which is a part of the 
supplemental routines 51, In block 132, the system 

10 displays a position attributes screen, which is shown 
diagrammatically in FIGURE 6. Then, still at block 136, 
the system waits for the user to make a selection. At 
block 137, the system evaluates the user selection. 

More specifically, if the user takes any action other 

IS than clicking the ALL STATUS button 138 of FIGURE 6, 
control proceeds at 141 to some other routine, which is not 
relevant to the present invention and which is not 
described in detail. Otherwise, if the user clicks the ALL 
STATUS button 138, control proceeds from block 137 to block 

20 142, where the system replaces the screen of FIGURE 6 with 
an expanded version thereof, which is shown in FIGURE 7 and 
which displays all possible attributes for the selected 
position. In block 142, the system also determines whether 
a workflow is already in progress for any of the attributes 

25 displayed in the screen of FIGURE 7. If so, then the 
system changes a CREATE PLANNED button 146 or 147 which 
corresponds to that attribute to a DISPLAY SUBMITTED 
button. Further, the system grays the rest of the line to 
the left of that button, to indicate to the user that it is 

30 not currently possible to propose a change for that 
particular attribute. The system then waits for user 
input . 

At block 151, the system checks to see if the user has 
clicked one of the CREATE PLANNED buttons 146 or 147. If 
35 not, or in other words if the user has taken any other 
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action, then control proceeds at 152 to some other routine, 
which is not relevant to the present invention and is 
therefore not illustrated in detail. 

In FIGURE 1, the CREATE PLANNED button 146 corresponds 
5 to an administrative assignment, which is a permanent 
assignment or transfer. The CREATE PLANNED button 147 
corresponds to a temporary duty (TDY) assignment, which is 
a temporary assignment such as a loan of a person to a 
given position for a limited time period. For purposes of 

10 facilitating an understanding of the present invention, it 
will be sufficient to describe in detail the handling of 
only one of an administrative assignment and a temporary 
duty assignment. With this in mind, an administrative 
assignment (permanent transfer} has been arbitrarily 

15 selected for discussion in greater detail, which 
corresponds to actuation of the CREATE PLANNED button 146. 
However, it will be recognized that the CREATE PLANNED 
button 147 would be handled in a generally similar manner. 
In more detail, when control proceeds from block 151 

20 to block 153, the system checks to see if the CREATE 
PLANNED button clicked by the user is the button 146 for an 
administrative assignment. If not, or in other words if 
the user clicked the CREATE PLANNED button 147 for a 
temporary duty assignment, then control will proceed at 154 

25 to another routine, which is not disclosed and described in 
detail. Otherwise, however, if the user clicked the CREATE 
PLANNED button 146, control will proceed from block 153 to 
block 156. At block 156, the system waits for the user 
to identify the person who is to be transferred to the 

30 selected position. The user identifies the person by 
typing the employee number of this person in the text box 
shown at 158 in FIGURE 7. Once the user has done this, 
control proceeds from block 156 to block 161, where the 
system checks to see if the position is already filled by 
35 an employee who is permanently assigned to that position. 
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If so, and since it is not possible for two employees to 
hold the same position at the same time, then the proposed 
transfer cannot be implemented, and control proceeds to 
block 162, where the system displays an appropriate error 
5 message. Control then proceeds from block 162 back to 
block 136. 

Alternatively, if it is determined at block 161 that 
there is no employee who is permanently assigned to the 
position of interest, then at block 163 the system checks 

10 to see if there is an employee who is ten^porarily assigned 
to the position of interest. If there is an employee who 
is ten^sorarily assigned, then it is possible to "terminate" 
or "delimit" the existing temporary assignment, effectively 
on the date that the proposed permanent, assignment would 

IS start, in order to implement the proposed permanent 
assignment to that position. Therefore, control proceeds 
to block 164, where the system displays a message warning 
that the temporary duty (TDY) assignment must be delimited 
in order to proceed, and requests user approval. Then, at 

20 block 166, the system checks to see whether the user has 
approved delimiting of the temporary assignment. If the 
user does not approve the delimiting, then the proposed 
permanent assignment is dropped, and control returns to 
block 136. On the other hand, if the user approves 

25 delimiting of the existing temporary assignment, then 
control proceeds to block 167, where the system sets a 
DELIMIT flag, after which control proceeds to block 168. 
Control also proceeds directly from block 163 to block 168 
if it is determined at block 163 that the position in 

30 question does not have any employee assigned to it on a 
temporary basis. 

At block 168, the system checks to see whether the job 
code for the position is the same as the job code 
associated with the person who is proposed for assignment 

35 to the position, namely the person whose employee number 
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has been entered in text box 158 of FIGURE 7. If the job 
codes of the employee and the position do not match, then 
the employee cannot be assigned to the position. Control 
therefore proceeds to block 169, where the system displays 
5 an appropriate error message. After that, control proceeds 
from block 169 back to block 136. On the other hand, if 
there is a match between the job codes for the employee and 
the position, then control proceeds from block 168 to block 
171. 

10 In block 171, the system checks to see whether the 

database 36 shows that the position in question will 
undergo a change in its associated job code at some future 
date. If so, then the job codes of the employee and the 
position would not match after that date, and therefore the 

15 employee cannot be assigned to the position now. Control 
therefore proceeds to block 172, where the system displays 
an appropriate error message, and then control returns to 
block 136. If no future change in the j ob code is 
scheduled, then control proceeds from block 171 to block 

20 173, where the system displays the name of the person who 
is proposed to be transferred. In particular, the name of 
the person would appear to the right of the text box 158 in 
FIGURE 7. The system then waits for the user to select the 
next action to take. The user has three options, which are 

25 handled in block 174. 

In particular, the user is permitted to cancel the 
proposed change, in which case control proceeds at 17 6 back 
to block 131. Alternatively, the user may elect to save 
the proposed change without submitting it for 

30 implementation, in which case control proceeds to block 
177, where the proposed change is saved with a "planned" 
status. Control then proceeds from block 177 back to block 
131. 

The third option is to submit the proposed change for 
35 implementation. If the user selects this option, then 
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control proceeds from block 174 to block 178, where the 
system saves the proposed change with "planned" status. 
Then, at block 179, the system checks to see whether the 
DELIMIT flag has been set by block 167. If so, then 
5 control proceeds to block 186, where the system delimits 
the existing temporary duty work assignment. In more 
detail, the system effects a change in the database 36 
which ends the temporary duty assignment, effective 
immediately. From block 186, control proceeds to block 
10 187. Control also proceeds directly from block 179 to 
block 187 if it is found at block 179 that the DELIMIT flag 
is not set- 

In block 187, the system sets the mode indicator to 
"SH", which is an indication that this particular proposed 
15 change was initiated from the screen of FIGURE 7 . Then, at 
block 188, control is transferred to a SUBMIT routine. 
This is the same SUBMIT routine mentioned above in 
association with block 120 of FIGURE 2. The SUBMIT routine 
will now be described in more detail with reference to 

20 FIGURE 8. 

FIGURE 8 is a flowchart showing the SUBMIT routine, 
which is a further portion of the supplemental routines 51 
of FIGURE 1. The SUBMIT routine interacts with the two 
tables which are indicated diagrammatically at 53 in FIGURE 

25 1. The first of these tables is the scenario table, which 
appears in this text as TABLE 1. The second of these two 
tables is the scenario attributes table, which appears in 
this text as TABLE 2- 

As previously discussed, the routine of FIGURE 2 sets 

30 the mode indicator to "SA" before calling the SUBMIT 
routine of FIGURE 8, whereas the routine of FIGURE 5 sets 
the mode indicator to "SH" before calling the SUBMIT 
routine of FIGURE 8. In block 201 of FIGURE 8, the system 
takes the mode value passed to it in the mode indicator by 

35 the calling routine, and makes a scenario list identifying 
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the rows in the scenario table (TABLE 1) which have this 
same value in the MODE column. For example, if the calling 
routine (FIGURE 5) set the mode indicator to "SH", the 
scenario list would identify the third and fourth rows of 
5 the scenario table. Alternatively, if the calling routine 
(FIGURE 2) set the mode indicator to "SA", the scenario 
list would identify the fifth through seventh rows of the 
scenario table. 

Each row of the scenario table corresponds to a 

10 respective scenario, a brief textual summary of which is 
given in the LTEXT column of that row. If the WORKFLOW 
OBJECT and EVENT columns of the row are blank, then no 
workflow is required for that scenario. On the other hand, 
if there are entries in the WORKFLOW OBJECT and EVENT 

15 columns, then a workflow may or may not be required, 
depending on information in the scenario attributes table 
(TABLE 2), as discussed later. As to those rows in the 
scenario table which do have an entry in the WORKFLOW 
OBJECT and EVENT columns, it will be noted that the entries 

20 differ from row to row. These different entries specify 
respective types of workflow which can be carried out by 
the workflow engine 43 (FIGURE 1). From block 201 of FIGURE 
8, control proceeds to block 206. In block 206, the system 
successively processes each of the scenarios from the 

25 scenario table which it included in the scenario list that 
it prepared in block 201. For each such scenario in the 
list, the system takes the entries from the OBJECT and 
SCENARIO columns of the scenario table (TABLE 1), and makes 
a list of rows or entries in the scenario attributes table 

30 (TABLE 2) which have identical entries in the OTYPE and 
SCENARIO columns and which have an "X" in the TRIGGER 
column. For example, if the mode were "SH", so that the 
scenario list included the third and fourth rows of the 
scenario table, the scenario attributes list would include 

35 the sixth and seventh rows of the scenario attributes 
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table. Alternatively/ if the mode was "SA", so that the 
scenario list included the fifth through seventh entries of 
the scenario table, then the scenario attributes list would 
include the eighth, seventeenth and eighteenth rows of the 
5 scenario attributes table. 

Each row in the scenario attributes table corresponds 
to a particular type of change which the user can propose, 
and it should be evident that several types of changes may 
be associated with a single given scenario. For example, 

10 change types corresponding to the eighth through sixteenth 
rows of the scenario attributes table all correspond to a 
single scenario, which is represented by the fifth row of 
the scenario table. 

The scenario attributes table has a TRIGGER column and 

15 an ACTIVATE column. If there is an "X" in the ACTIVATE 
column, then the type of change associated with the row can 
be "activated", or in other words implemented immediately, 
without any need for a workflow to obtain approvals. That 
is, if there is an "X" in the ACTIVATE column, then the 

20 entries in the WORKFLOW OBJECT and EVENT columns in the 
corresponding row of the scenario table can be ignored. If 
there is an "X" in the TRIGGER column, then the change type 
associated with that row of the scenario attributes table 
is given a greater level of importance during processing of 

25 proposed changes, as described in more detail later. Also, 
if there is an "X" in the TRIGGER column, then the entries 
in the WORKFLOW OBJECT and EVENT columns of the 
corresponding row of the scenario table specify a 
particular workflow procedure associated with this 

30 particular row of the scenario attributes table. 

From block 206, control proceeds to block 207, which 
is the start of a loop in which the system processes the 
entries in the scenario attributes list. In block 207, the 
system checks to see if it has processed all entries in the 

35 scenario attributes list. When all entries have been 
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pr cessed, then control will proceed to block 208. The 
first time through the loop, how ver, control will proceed 
to block 209, where the system gets the next entry from the 
scenario attributes list. The first time through the loop, 
5 this will be the first entry in the list. Control then 
proceeds to block 212. 

When the SUBMIT routine of FIGURE 8 is entered, the 
system will necessarily include one proposed change which 
has been saved with "planned" status, which is the proposed 

10 change that the user has submitted for implementation. 
However, as evident from the preceding discussion, the user 
also has the option of saving proposed changes with a 
"planned" status, without immediately submitting them for 
implementation. Thus, the system may also include a number 

IS of other proposed changes which have been saved with 
"planned" status but which have not been implemented. 

When any proposed change is passed to the SUBMIT 
routine of FIGURE 8 for implementation, the SUBMIT routine 
will implement not only that proposed change, but also all 

20 other proposed changes which have been saved with "planned" 
status, and which fall within the same mode category as the 
change which has been submitted. Stated differently, when 
a proposed change is submitted for in^lementation from the 
screen of FIGURE 4, all proposed changes which have been 

25 saved for the screen of FIGURE 4 are considered for 
implementation. Similarly, when a proposed change is 
submitted for implementation from the screen of FIGURE 7, 
all proposed changes for the screen of FIGURE 7 are 
considered for implementation. 

30 Thus, in block 212, the system checks the database 36 

for any proposed change which has been saved with "planned" 
status, and which corresponds to the current entry from the 
scenario attributes list. This is done by taking the 
values for the DATA IDENTIFIER, SUBTY, and STATUS columns 

35 from the selected row of the scenario attributes table, and 
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then looking for a proposed change which has been saved in 
the database 36 and which has identical values specified 
for data identifier, subtype and status. If such a 
proposed change is found, then a FOUND flag is set in the 
5 associated row of the scenario table, in block 213. 

Since the FOUND flags are each closely associated with 
a respective row of the scenario table, the disclosed 
ejobodiment includes them as a part of the scenario table 
(TABLE 1), in the form of a separate column in that table. 
10 However, since this is the only portion of the scenario 
table which dynamically changes during system operation, 
the FOUND flags could alternatively be implemented in the 
form of a further table which is logically separate from 
the scenario table and the scenario attributes table. It 
15 is assumed that the FOUND flags are all in a reset state 
when the SUBMIT routine begins. If necessary, the FOUND 
flags could all be forcibly cleared at the start of the 
SUBMIT routine, although the flowchart of FIGURE 8 does not 
expressly show this. From block 213, control proceeds back 
20 to block 207. 

If the system determined at block 212 that the 
database 36 did not include any proposed change 
corresponding to the current entry of the scenario, 
attributes lists, then control would proceed to block 214, 
25 where the system checks to see whether the OBLIG column of 
the associated row of the scenario table contains an "X". 
If so, then this particular scenario is required for the 
current object and mode, and the absence from the database 
36 of a corresponding proposed change represents an error. 
30 Accordingly, control proceeds from block 214 to block 217, 
where the system displays an appropriate error message. 
Then, at 218, the system exits the SUBMIT routine by 
returning to the calling program. If, on the other hand, 
it was determined at block 214 that the corresponding row 
35 of the scenario table did not have an "X" in the OBLIG 
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column, then control would have proceeded from block 214 
back to block 207, 

When it is determined at 207 that all entries in the 
scenario attributes list have been processed, the system 
5 will exit the loop by proceeding to block 208. Block 208 
is the beginning of a loop in which the system will process 
each row of the scenario table for which the FOUND flag has 
been set. If none of the FOUND flags have been set, then 
the system immediately exits the SUBMIT routine at 221 by 

10 performing a return to the calling routine. However, if at 
least one FOUND flag has been set, then control proceeds to 
block 222, where the system selects the next scenario 
associated with a FOUND flag. The first time through the 
loop, this will be the first scenario having its FOUND flag 

15 set. 

At block 223, the system checks the current row of the 
scenario table to see if the MGR DOMAIN column contains an 
"X". The presence of an "X" means that, if all of the 
elements of the proposed change are within the domain of a 

20 given manager, the manager has the authority to make the 
change, and it is not necessary to initiate a workflow in 
order to get the approval of anyone else. If there is no 
"X", then control proceeds to block 224. Otherwise, 
control proceeds to block 227, where the system determines 

25 whether all of the elements or objects affected by the 
proposed change are within the domain of the manager 
proposing the change. If not, then control proceeds to 
block 224. Otherwise, at block 228, the system sets an 
ACTIVATE ALL flag. From block 228, control proceeds to 

30 block 224. 

Block 224 is the start of a loop which processes each 
entry or row of the scenario attributes table that 
corresponds to the current scenario from the scenario 
table. If all such entries of the scenario attributes 

35 table have been processed, then control proceeds to block 
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229. Otherwise, control proceeds to block 231, where the 
system gets the next appropriate entry from the scenario 
attributes table. The first time through the loop, this 
will be the first entry corresponding to the current 
5 scenario. 

At block 232, the system checks to see whether this 
row or entry of the scenario attributes table has an "X" in 
the ACTIVATE column. If so, then control proceeds to block 
233/ where the system checks to see whether the data to be 

10 activated/ or in other words the proposed change, is 
present in the database 36* If not, control proceeds to 
block 224. Otherwise/ control proceeds to block 234 where 
the system activates that particular data. In other words, 
the system implements the change in question by making 

15 appropriate changes in the database 36. From block 234/ 
control proceeds back to 224. 

If it was determined in block 232 that the ACTIVATE 
column did not include an "X"/ then control would proceed 
to block 237, where the system checks to see whether the 

20 ACTIVATE ALL flag has been set. If so, then control 
proceeds to block 233. If not, control proceeds back to 
block 224. When all rows in the scenario attributes list 
which correspond to the current scenario have been 
processed, control proceeds from block 224 to block 229. 

25 In block 229, the system checks to see whether the 

current scenario has an entry in the EVENT column of the 
scenario table. If not, then no workflow is required, and 
the associated data has already been activated (at block 
234} . Control proceeds to block 238, where the system 

30 displays a message indicating that the data has been 
activated, or in other words that one or more proposed 
changes have been implemented. Otherwise, control proceeds 
to block 239, where the system checks to see whether the 
ACTIVATE ALL flag is set. If so, then no workflow is 

35 required, because all elements affected by the change are 
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within the domain of a given manager, and because the data 
has therefore already been activated at block 234. Control 
therefore proceeds from block 239 to block 238, for the 
display of the message indicating that the data has been 
5 activated. 

On the other hand, if the ACTIVATE ALL flag is not 
set, control proceeds from block 239 to block 241. Block 
241 is the start of a loop in which the system processes 
each entry in the scenario attributes table which 
10 corresponds to the current scenario. In block 241, the 
system checks to see whether it has processed all such 
entries. The first time through the loop it will find that 
it has not, and it will proceed to block 242, where it will 
select the next entry in the scenario attributes table « 
15 The first time through the loop, this will be the first 
qualifying entry. 

Control then proceeds to block 243, where the system 
checks to see whether that entry or row of the scenario 
attributes table has an "X* in the ACTIVATE coliunn. If so, 
20 then no workflow is required, and control proceeds back to 
block 241. Otherwise, control proceeds to block 244, where 
the system checks to see whether the database contains a 
proposed change which corresponds to the current entry or 
row of the scenario attributes table. If the database has 
25 no corresponding data, then there is no need for a 
workflow, and control proceeds from block 244 back to block 
241, Otherwise, control proceeds to block 247, where the 
system modifies the database 36 to switch that proposed 
change from "planned" status to "sxibmitted" status, to 
30 indicate that a workflow is in progress for that proposed 
change. Control then proceeds from block 247 back to block 
241. 

When it is determined that all entries in the scenario 
attributes table which correspond to the current scenario 
35 have been processed, control proceeds from block 241 to 
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block 248, where the system publishes the event specified 
in the scenario table in order to initiate a workflow. In 
particular, the entries in the WORKFLOW OBJECT and EVENT 
columns of the scenario table are used in an interaction 
5 ^ with the workflow engine 43 (FIGURE 1) in order to initiate 
a workflow. Then, still in block 248, the system displays 
a message indicating the workflow has been initiated. From 
this point on, the workflow is handled by the workflow 
engine 43, the details which are not part of the present 
10 invention and are therefore not discussed here in detail. 
The workflow engine 43 will effect an appropriate routing 
of the workflow in order to obtain the necessary approvals, 
and will then change the database 36 so as to inclement the 
proposed changes that have been approved. 
15 In FIGURE 6, control proceeds from each of blocks 238 

and 248 to block 249, where the system clears the ACTIVATE 
ALL flag* Control then proceeds from block 249 back to 
block 208. When it is determined at block 208 that the 
system has processed each scenario/row of the scenario 
20 table for which the FOUND flag is set, control proceeds 
from block 208 to block 221, and a return is made to the 
calling routine. 

In the screens of FIGURES 4 and 7, each attribute that 
can be changed has a respective CREATE PLANNED button. 
25 Alternatively, however, where a given attribute currently 
has no associated information, for example where a position 
currently does not have any person assigned to it, the 
CREATE PLANNED button for that attribute can be omitted. 
If the user begins entering information for that attribute, 
30 the system can automatically treat the entry of information 
as a "create planned** event. 

The present invention provides a number of technical 
advantages. One such technical advantage is that a user 
can save one or more proposed changes to a database of 
35 information without submitting the changes for 



wo 00/19345 



PCT/US99/22005 



26 

implementation/ and that a plurality of the saved proposed 
changes which are r lated to each other can subsequently be 
simultaneously processed for implementation. A further 
advantage results from the use of a table structure to 
5 facilitate the processing and implementation of proposed 
changes/ the table structure being accessed to determine 
which saved proposed ch2mges are related to each other. A 
further advantage results from use of the table structure 
to determine when a workflow is required. Still another 

10 advantage results from use of the table structure to 
determine which workflow to initiate *^en a workflow is 
required. In the specific context of SAP software, the 
invention provides the advantage of permitting a workflow 
to be initiated or triggered from within the personnel 

15 development module. 
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TABLE 2 - SCENARIO ATTRIBUTES TABLE 
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Although one embodiment has been illustrated and 
described in detail, it will be understood that various 
25 changes, substitutions and alternations can be made therein 
without departing from the spirit and scope of the present 
invention, as defined by the following claims. 
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mfflT rT.RTMED TS! 

1. A method/ comprising the steps of: 
maintaining a database of information; 
accepting from a user through a user input apparatus 

a proposed change to the database and a specified status 
therefor; 

saving a proposed change when the specified status 
therefor is a first status, without initiating 
io^lementation thereof; and 

processing a proposed change by initiating 
implementation thereof when the specified status therefor 
is a second status different from the first status , said 
processing step including the step of initiating a workflow 
where the proposed change having the second status requires 
a workflow. 

2. A method according to Claim 1, wherein said 
processing step includes the step of promptly implementing 
the proposed change in the database if no workflow is 

20 required therefor. 

3. A method according to Claim 1, wherein said 
processing step includes the step, when a workflow is 
required/ of delaying implementation of the proposed change 

25 in the database until after successful completion of the 
workflow. 

4. A method according to Claim 3/ wherein said 
processing step includes the step of promptly in^lementing 

30 the proposed change in the database if no workflow is 
required therefor. 



10 
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5. A method according to Claim I, including a 
predefined table structure which identifies possible 
changes of a first type and possible changes of a second 
type different from the first type, the proposed change 
5 being one of the first and second types, the table 
structure further having for each of the first and second 
types a respective indicator that c^ have one of first and 
second states, the first state indicating that a workflow 
is unnecessary for a proposed change of that type which 

10 affects only a domain of the user proposing the change; and 
wherein said processing step includes the step of 
initiating implementation of the proposed change without a 
Workflow if the corresponding indicator has the first state 
and if the proposed change affects only the domain of the 

15 user proposing that change. 

6. A method according to Claim 1, including the step 
of responding to execution of said processing step for a 
first proposed change by searching for a second proposed 

20 change which has been saved with the first status, and then 
carrying out said processing step for the second proposed 
change . 

7. A method according to Claim S, including the step 
25 of changing the status of the second proposed change from 

the first status to the second status, 

8. A method according to Claim 6, wherein the first 
proposed change is a first type of change, and wherein said 

30 searching step includes the step of ignoring saved proposed 
changes which are of a second type different from the first 
type. 
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9. A method according to Claim 8, including a 
predefined table structure having a portion which 
identifies possible changes of the first type and possible 

5 changes of the second type, said searching step including 
the step of accessing the table structure. 

10. A method according to Claim 6/ including a 
predefined table structure having a first portion which 

10 identifies possible changes of the first type and possible 
changes of the second type, and having a second portion 
which identifies when a workflow is required for each of 
the possible changes, said searching step including the 
step of accessing the table structure. 

15 

11. A method according to Claim 10, wherein the first 
portion of the table structure identifies for each of the 
possible changes a respective workflow to be initiated when 
the second portion thereof indicates that a workflow is 

20 required. 

12. A method according to Claim 10/ wherein the table 
structure includes first and second tables which are 
separate/ and which respectively have therein the first and 

25 second portions of the table structure. 

13. A method according to Claim 1, including the step 
of permitting a user to switch a saved proposed change from 
the first status to the second status/ and thereafter 

30 carrying out said processing step for the saved proposed 
change. 
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14. A method according to Claim 1/ including first 
and second types of proposed changes; and wherein said 
processing step includes the step of responding to a first 
5 proposed change which has the second status by aborting 
said processing step unless one of a first criterion and a 
second criterion is satisfied^ the first criterion being 
that the first proposed change is of the first type^ and 
the second criterion being that there is a second proposed 
10 change which has been saved with the first status and is of 
the first type. 
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